Conversation
WalkthroughThe changes refactor membership client construction across the organization commands, replacing previous constructors with new ones that adjust return value handling. Additionally, error handling in the deployment process is modified to defer error reporting from the completion-wait phase to the render phase, with log rendering behavior adjusted accordingly. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
c5dd351 to
2aca477
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
cmd/cloud/apps/deploy.go (1)
182-189:⚠️ Potential issue | 🟡 Minor
waitRunCompletionis invoked twice when--wait=true.
Run()callswaitRunCompletionat line 90 when the--waitflag is true, thenRender()calls it again at line 187 under the same condition. This causes unnecessary API polling on success (re-polling a deployment that has already reached terminal state). On error, the second call overwritesc.store.Runandc.store.logs, making the early error check at line 173 ineffective since it inspects state that will be overwritten by the second wait.
No description provided.